- Проект архитектуры контроля
-
5.3.1 Проект архитектуры контроля и управления
Проект архитектуры контроля и управления определяет верхний уровень систем контроля и управления АС (см. раздел В.4 приложения В), связи между этими системами и средства обеспечения согласованного интерфейса между этими системами.
5.3.1.1 Основные требования
a) Проект архитектуры контроля и управления должен охватывать все аспекты контроля и управления с тем, чтобы выделить функции контроля и управления, важные для безопасности, приведенные в 5.2.
b) Проект должен распределять контроль и управление по достаточному числу систем и оборудования, чтобы соответствовать требованиям к:
- независимости функций в различных эшелонах защиты;
- соответствующему разделению систем по классам;
- выполнению требований к физическому разделению и электрической изоляции в соответствии с ограничениями, вытекающими из условий внешней среды и расположения АС, анализа опасностей, а также связанными с обслуживанием при эксплуатации (см. 5.3.1).
c) Проект архитектуры должен предусматривать достаточное число систем и подсистем, чтобы принцип единичного отказа выполнялся для функций категории А во всех допустимых конфигурациях систем и АС (см. 7.5 МАГАТЭ 50-SG-D3).
d) Каждая система контроля и управления должна быть классифицирована в соответствии с ее назначением в системе функций контроля и управления согласно установленной категории (см. таблицу 2).
e) Интерфейс с оборудованием АС и взаимосвязи между системами контроля и управления должны определяться в составе проекта архитектуры для того, чтобы установить:
- распределение сигналов (измерений) по различным функциям, важным для безопасности;
- выбор и приоритетность исполнительных сигналов различных систем;
- пути прохождения сигналов и оборудование, общее для выполнения автоматических функций или ручного управления на различных уровнях глубокоэшелонированной защиты.
f) Описание систем, оборудования и их взаимодействия в проекте архитектуры контроля и управления должно быть достаточно подробным, чтобы способствовать анализу вопросов безопасности контроля и управления.
Таблица 2 - Соотношение между классами систем контроля и управления и категориями ФСО
Категории функций контроля и управления, важных для безопасности
Соответствующий класс систем контроля и управления, важных для безопасности
А
(В)
(С)
1
В
(С)
2
C
3
Примечание - Функции категории А могут выполняться только системами класса 1; функции категории В - системами классов 1 и 2; функции категории С - системами классов 1, 2 и 3.
5.3.1.2 Интерфейсы человек - машина
a) Проект архитектуры контроля и управления должен распределять системы с интерфейсом человек- машина по различным помещениям АС, предназначенным для управления и наблюдения, включая блочный пункт управления (далее - БПУ) и дополнительные помещения, резервный щит управления (см. МЭК 60965), местные щиты управления и пункт управления противоаварийными действиями, с необходимой степенью резервирования, с учетом ограничений, накладываемых эксплуатацией и обслуживанием оборудования АС (см. 5.1.1).
b) Проект должен опираться на принципы эксплуатации, установленные в проекте АС (см. 5.1.1), включая:
- принципы приоритетности между автоматическими сигналами и сигналами управления, вводимыми вручную;
- принципы приоритетности между различными системами взаимодействия человеко-машинных интерфейсов при нормальной эксплуатации, аварии и эксплуатации после аварии;
- принципы приоритетности между основными и резервными человеко-машинными интерфейсами;
- принципы переключения основных и резервных человеко-машинных интерфейсов.
c) Проект архитектуры должен определять, как оператор получит извещения о сбоях и отказах, регистрируемых средствами диагностики отдельных систем. Форма представления должна быть такой, чтобы оператор имел возможность:
- немедленно по индикации опознать отказ и отличать его от других индицируемых эксплуатационных данных;
- решить, не следует ли применить ручное управление для перевода АС в безопасное состояние;
- определить системы, которые следует восстановить с помощью обслуживающего персонала.
d) Проект архитектуры контроля и управления должен соответствовать основным решениям по технологии систем человеко-машинного интерфейса (например, компьютеризированная или традиционная). Для представления информации операторам должны использоваться более сложные системы, если это снижает влияние человека на возникновение отказа и это влияние можно сократить благодаря получению более качественной информации. Уровень отказов компьютерных информационных систем вследствие отказов по общей причине следует рассматривать в сравнении с уровнем отказов вследствие влияния человеческого фактора.
e) В проекте:
- должны быть указаны функции, управляемые человеком и управляемые автоматически в соответствии с анализом задач, выполненным в проекте АС (см. 5.1.1);
- должна быть определена способность системы контроля и управления осуществлять необходимую обработку информации и завершать задачи, определенные в результате взаимодействия с оператором (см. 3.2.2 МЭК 60964);
- должно быть обеспечено соответствие информации и времени, имеющихся у оператора для выполнения управления вручную, требованиям проекта АС (см. 5.1.1).
f) Для обеспечения эффективности взаимодействия человек - машина в проекте БЩУ и других щитовых помещений АС должны использоваться технические средства, основанные на требованиях МЭК 60964 и МЭК 60965.
g) При анализе проекта должны рассматриваться задачи оператора и оптимизация требований к взаимодействию человек - машина при выполнении как важных для безопасности, так и не влияющих на безопасность задач.
5.3.1.3 Средства передачи данных
Средства передачи данных между системами, образующими архитектуру контроля и управления, включают в себя все линии, обеспечивающие прохождение одного или более сигналов или сообщений по одному или более пути с использованием различной мультиплексной техники.
a) Линии передачи данных должны соответствовать общей спецификации требований к рабочим характеристикам (см. 5.2) при всех условиях работы АС.
b) Архитектура и технология линий передачи данных должны обеспечивать соблюдение требований независимости систем. Кроме физического разделения и электрической изоляции в проекте должны быть предусмотрены меры, гарантирующие отсутствие влияния неполадок в системе передачи данных на работу средств обработки.
c) Линии передачи данных должны включать в себя средства проверки работоспособности коммуникационного оборудования и полноты передаваемых данных.
d) Для устойчивости к отказам должно быть обеспечено резервирование линий передачи данных.
е) Линии передачи данных должны быть спроектированы так, чтобы передача данных и выполнение функции более высокой категории безопасности не нарушались при передаче данных в системе более низкого класса. Например, выполнение тестов на работоспособность не должно мешать выполнению функции высшей категории.
5.3.1.4 Инструментальные средства
a) В проект архитектуры контроля и управления должны быть включены инструментальные средства, выполняемые обычно на базе компьютеров (см. 4.2 МЭК 60880-2), которые обеспечивали бы устойчивость обмена данными между системами контроля и управления, работающими совместно, и гарантировали бы сохранность базы данных АС.
Примечание - Специальные инструментальные средства для отдельных систем выбирают на стадии разработки спецификации системы (см. 6.1.3.2).
b) Инструментальные средства должны применяться на всех фазах полного жизненного цикла безопасности, за счет чего может быть достигнуто повышение качества и надежности функций, важных для безопасности, например, для поддержки:
- аспектов, связанных с проектом интерфейсов между системами контроля и управления;
- общей интеграции и приемки распределенных функций.
5.3.1.5 Защита от отказов по общей причине
Цель проекта архитектуры контроля и управления - обеспечить меры защиты от отказов по общей причине систем контроля и управления путем введения различных защитных мер против одних и тех же постулированных исходных событий (см. 5.1.1).
Эти меры защиты включают в себя:
- проектные решения по обеспечению устойчивости к опасным событиям на АС. Внешние и внутренние опасности (см. 5.1.3), влияние которых не исключено для ограниченной части архитектуры контроля и управления и которые могут привести к отказам по общей причине;
- проектные решения, направленные против отказов, которые могут быть вызваны изменениями в нагрузке АС. Включение некоторых компонентов оборудования, например, усилителей мощности и реле, или ввод компонентов программного обеспечения, например, таких как сбор входных данных, передача данных и переключение эксплуатационных режимов, могут зависеть от событий, происходящих на АС;
- проектные решения по минимизации использования общих ресурсов в архитектуре контроля и управления и взаимодействия человек- машина для различных уровней защиты. Такие общие ресурсы можно представить в виде использования одного сигнала измерения или обычной технологической операции в различных управляющих действиях;
- решения по минимизации риска систематических сбоев. В любой системе контроля и управления существует риск проектных ошибок или присутствуют ошибки, связанные с реализацией. Поэтому возможность сбоя программного обеспечения, вызывающего отказ, нельзя исключить при анализе любого отказа системы. Если используются одинаковые программные модули в сходных условиях в разных компьютерных системах, существует риск отказа по общей причине вследствие такой ошибки в программном обеспечении;
- использование разнообразия. Разнообразие обеспечивает несколько различных путей обнаружения значительных событий и реагирования на них для увеличения защиты от отказа по общей причине. К видам разнообразия относятся разнообразие персонала, разнообразие сигналов (использование разных измерительных параметров для инициирования защитных действий), функциональное разнообразие, разнообразие проектных решений и проверок, разнообразие программного обеспечения и оборудования;
- принятие стратегических решений по ограничению сложности. Использование компьютеров способствует выполнению более сложных алгоритмов и процессов, чем это возможно с помощью оборудования с жесткой логикой. При более сложных требованиях возможность ошибок и просчетов в спецификации требований и ошибок в проекте и при реализации становится значительно больше, чем в случае простых требований.
5.3.1.5.1 Устойчивость к внутренним и внешним воздействиям, которые могут привести к отказу по общей причине
Необходимо принять меры, обеспечивающие работоспособность комплекса безопасности, выполняющего функции категории А, которые требуется поддерживать на случай противодействия внутренним и внешним опасным воздействиям.
Эти меры включают в себя:
- разделение, например, размещение резервных частей системы в различных помещениях;
- независимость, например, систем подогрева, вентиляции и кондиционирования воздуха и отдельных источников энергоснабжения для каналов и систем;
- защита, например, от огня, воздействия химических веществ и вибрации;
- проектирование, например, оборудования в соответствии со стандартами МЭК по электромагнитной совместимости;
- квалификацию по воздействиям окружающей среды, например, по отношению к сейсмическим воздействиям (см. 6.4).
5.3.1.5.2 Защита от отказов по общей причине вследствие изменения потребности в энергии
a) Необходимо определить выполняющие функции категории А компоненты систем контроля и управления, работа которых зависит от нагрузки станции. Возможные виды отказов и их последствия (включающие в себя их влияние на компоненты, работа которых не зависит от режима нагрузки станции) должны быть оценены с точки зрения вероятных источников и эффектов отказа по общей причине.
b) Риск отказов по общей причине систем класса 1 должен быть минимизирован за счет использования систем контроля и управления и обеспечивающих систем, которые работают в одном и том же режиме как до, в процессе, так и после изменения нагрузки, т.е. их работа не должна зависеть от графика приложения нагрузки.
5.3.1.5.3 Защита за счет проектных решений по архитектуре систем контроля и управления и человеко-машинному интерфейсу
a) Различные рубежи защиты против постулированных исходных событий должны быть оснащены независимыми системами или подсистемами (см. примечание 1 к 5.1.1). Если используются общие ресурсы, они должны соответствовать плану обеспечения надежности комплекса безопасности.
b) Должны быть предусмотрены независимые средства контроля и управления функциями и системами, важными для безопасности АС (например, мультиплексные линии передачи данных или компьютеры), чтобы во время отказа имелась достаточная информация, необходимая для безопасной эксплуатации АС.
c) Если управление функциями категории А или В выполняется вручную как дублирующее действия автоматики, то возможность отказа по общей причине в процессе этих действий должна быть сведена к минимуму.
d) Если одна функция категории А может инициировать действие системы безопасности, а другая функция категории А, применяемая при других обстоятельствах, может вызвать противоположное действие, необходимо провести анализ с целью определения того действия, которое требуется выполнить в условиях отказа систем контроля и управления.
5.3.1.5.4 Защита от отказа по общей причине вследствие систематических сбоев
a) Планирование высокого качества, предусмотренное при разработке и создании различных систем контроля и управления комплекса безопасности, должно исключать случаи невыявленных отказов и, таким образом, свести риск отказов этих систем по общей причине к минимуму. Настоящий стандарт содержит требования, которые следует применять для обеспечения качества систем контроля и управления различных классов.
b) Систематические отказы должны выявляться средствами самоконтроля (исключая использование ручек настройки, аппаратуры самоконтроля, проверок правдоподобия), а выявляемые отказы должны переводить систему(ы) в предварительно установленное, предпочтительно безотказное состояние, при этом оператор должен получать сообщение об отказе.
c) Если требуемая надежность безотказного выполнения функции безопасности больше, чем надежность, полученная в результате оценки безотказного состояния данной системы, то проект данной системы следует переработать.
Примечание 1 - Требуемая степень защиты от отказов зависит от категории выполняемых функций.
Примечание 2 - Цель настоящего подраздела - дать общие сведения. Детальные требования к защите от отказов по общей причине вследствие ошибок в программном обеспечении для функций категории А приведены в 4.1 МЭК 60880-2.
5.3.1.5.5 Защита за счет разнообразия
a) В случае, если требуется высокая надежность комплекса безопасности, при проектировании архитектуры контроля и управления следует опираться на принцип разнообразия, особенно если имеются неопределенности в выполненных в проекте оценках.
b) Необходимо рассмотреть методы функционального разнообразия и разнообразия сигнала. Эти методы являются эффективными для снижения вероятности отказа по общей причине, возникшего вследствие ошибок в спецификациях требований или в спецификации и установке прикладного программного обеспечения.
c) Разнообразие оборудования может быть эффективным против отказа по общей причине компонентов аппаратного обеспечения и может обеспечить защиту против сбоев программного обеспечения системы. В частности, ее следует рассматривать при создании сложных систем, если опыт эксплуатации подобных систем ограничен.
d) Следует использовать разнообразие процедур или методов верификации и валидации (например, разнообразие оборудования для электромагнитных испытаний, испытания на взаимную совместимость с использованием эмулятора и пр.), что дополнительно поможет избежать отказов по общей причине без усложнения системы защиты.
e) Если для защиты против отказа по общей причине используется защита за счет разнообразия, то в проект следует включить анализ ее эффективности. Как положительный, так и отрицательный результат следует зафиксировать и отразить в документации (см. 5.3.3).
5.3.1.5.6 Стратегические решения по ограничению сложности
Для того, чтобы снизить до минимума вероятность отказа по общей причине из-за сложности систем, проектирование архитектуры контроля и управления должно включать в себя анализ, показывающий, что степень применения компьютеров вместо систем, построенных на жесткой логике и степень участия человека приемлемы сточки зрения обеспечения безопасности.
Примечание - Такой подход может зависеть от национального опыта, позиции регулирующего органа и надежности компьютерных технологий.
Словарь-справочник терминов нормативно-технической документации. academic.ru. 2015.
